！ 本篇文章將會介紹 第三週回顧：Agent 已經會自己發文了，期望大家都能看懂一雙「網頁的手」怎麼從安裝練到無人值守發文 :D
W1 我們把 agent 訓練成會寫文章的員工，W2 給它排班表、哨子與防護網，W3 則補上最後一塊拼圖：一雙真的能操作網頁的手。六天從 agent-browser 安裝、persistent profile 登入、填表、截圖驗收，一路打到 iT 邦幫忙發文實戰上下集。今天照慣例盤點：攤開 W3 的拼圖地圖、用 logs/ 的真實數字交成績單，外加本週唯一一場事故屍檢——20:00 那一發死於家裡斷網。先講結論：20 天零斷更，W3 六天六發全部上架，人工介入只有一次，而且事後對錶發現，補發保險其實早就就位，人只是搶快了 72 秒。
讀完這篇你會學到：
config.sh 的 BROWSER_PROFILE
# 進到系列 repo
cd /Users/benben/ai/automations/ironman
# W3 的發文成績單：最後六行就是 d15–d20
tail -6 state/published.log
# 每天一張的發佈存證截圖
ls screenshots/ | grep publish-d
先把這週六篇文章收攏成一張地圖：
article_type 陷阱、CodeMirror 真身、select2 遊戲規則publish.sh，MODE 分流 + 輪詢 URL 判成敗這六塊拼起來，就是 publish.sh 現在的樣子：launchd 20:00 叫醒它，它開著真 Chrome、帶著 profile 與反偵測三件套走進發文頁，填表、驗證、點擊、輪詢 URL、截圖、touch flag、跟 Discord 回報——整條路沒有人類參與。這個系列本身就是這套系統發的，你現在讀到的每一篇都是它的實績。
數字全部出自 logs/generate-*.log 與 state/published.log，沒有一個是編的：
| 天 | 生成耗時 | 嘗試 | 字數 |
|---|---|---|---|
| 15 | 4 分 38 秒 | 1 | 1,587 |
| 16 | 6 分 56 秒 | 1 | 1,686 |
| 17 | 5 分 44 秒 | 1 | 1,505 |
| 18 | 3 分 52 秒 | 1 | 1,524 |
| 19 | 4 分 40 秒 | 1 | 1,691 |
| 20 | 6 分 13 秒 | 1 | 1,743 |
六天全部第一次嘗試就過關，合計 32 分 03 秒、平均 5 分 20 秒一篇；字數穩定落在 1,505–1,743；state/ 裡的 quarantine-* 隔離檔停格在 d09，W3 一件都沒有。對照 W2 那場五連殺事故，生成端已經從「需要保鑣看著」進化到「自律上班」。
發文端更有感。點下「發表文章」到 URL 確認成功，六次實測全落在 6–8 秒；整個 job 從 launchd 觸發到 flag 落地，多數日子 30 秒內收工。d19 的 log 節錄：
# 從點擊到確認成功只花 6 秒（publish-20260929.log 節錄）
[2026-09-29 20:00:19] 點擊發佈（第 1/3 次）
[2026-09-29 20:00:25] 發佈成功：https://ithelp.ithome.com.tw/articles/10418879
六篇文章依序上架在 10417031 到 10419308，screenshots/ 裡 publish-d15 到 publish-d20 一天一張、全部對得起來。
小小小測驗：你知道 W3 這六天發文，Cloudflare Turnstile 人機驗證實際跳出來幾次嗎？
答案：零次。六天的 log 都寫著「頁面無 Turnstile 元件，跳過 token 等待」。但 D1 開賽那天它真的出現過（screenshots/還留著 turnstile-timeout 存證），所以程式裡那段條件式等待一個字都不能刪——防禦性程式碼的價值，本來就不是靠天天出勤證明的。
週日 20:00，publish.sh 準時起床，卻在開發文頁那一步直接斷氣：
# publish-20260927.log 節錄：家裡網路正好在那幾分鐘斷線
[2026-09-27 20:00:18] d17 發文來源：/Users/benben/ai/automations/ironman/articles/2026-09-27-d17.md
✗ Navigation failed: net::ERR_INTERNET_DISCONNECTED
[2026-09-27 20:00:27] FATAL: 無法開啟發文頁（profile 可能未登入，見 CALIBRATION.md）
這個 FATAL 死得很健康：沒有半填的表單、沒有誤觸的按鈕，Discord 當場收到 error 告警。20:13 網路恢復，我手動重跑一發過關；20:15:05 補發 job 準時醒來，看到 flag 已存在，安靜退場。有意思的是時間差：我 20:13:53 按下重跑，補發 job 20:15:05 才起床——人只快了 72 秒。就算我睡死，保險也會在兩分鐘後自動理賠。W2 埋的 republish 保險第一次「幾乎」實戰：它可以沒派上用場，但不能不存在。
順帶解答 d20 為什麼慢：20:00 是全台鐵人賽作者的發文尖峰，光開草稿頁與驗證就從 20:00:05 磨到 20:01:52。腳本的等待策略把這些延遲全部吸收，沒有任何一步誤判逾時——慢不是故障，把「慢」誤判成「死」才是。
# 每天一枚的發佈勳章：目前 19 枚，今晚 20:15 後變 20
ls state/ | grep published- | wc -l
# 19
一句話總結現況：生成、發文、補發、告警已全部無人值守，人只剩兩個工作——維護 outline.md 這份事實來源，以及偶爾在斷網時當一次 72 秒的英雄。 但誠實盤點，系統還有三筆欠帳：生成與發文目前是兩個獨立 job 靠檔案系統交接，稱不上正式的管線；備援只有單層，沒有重試鏈；而且沒有任何煞車機制，萬一腳本想發佈不該發佈的東西，只能靠機敏掃描與人工喊卡。這三件事正是 W4 的全部：管線整合、備援設計、進度追蹤、日誌稽核、異常自癒、安全煞車——把「能跑」煉成「敢睡」。
screenshots/。條件式檢查的成本只是一次 DOM 查詢，刪掉的風險卻是某天深夜發文被靜默卡死。低成本的防禦，留著。下一篇我們要介紹「全管線整合：19:00 生成 → 20:00 發文」，把 generate.sh 與 publish.sh 從「兩個剛好排在一起的 job」升級成有狀態檔交接的一條龍管線，W4 正式開張，敬請期待！
參考資料：
有任何疑問但沒有 iT 邦幫忙帳號，或是想匿名提問？
歡迎到 https://dev.benben.me/q/Z5442T 提問或加油打氣，沒意外的話會在完賽之後一起回答 :D
iThome鐵人賽
看影片追技術